S R E V I N U Ite It Type-oriented Logic Meta Programming

code often only depends on interfaces and purposefully ignores the implementation details of a speci c class. Hence it should be possible to write abstract code independent of the class hierarchy. In most class-based languages this is impossible because method implementations are associated with a speci c class. Therefore, abstract code usually ends up in an abstract class which depends on subclasses to ll in the implementation details. Consider the abstract class in gure 1.2 implementing the Searchable interface for collections that provide a way of enumerating their elements. The problem with this abstract class is that it is unclear where to insert it into the class tree. The problem becomes exponentially worse when there are several abstract interface implementations. A better, more \Type-Oriented Programming" avored solution can be accomplished in some parametric type systems by simulating a mixin as a parametric class inheriting from one of its parameters. Not all parametric type systems allow inheriting from type parameters because of implementation-related restrictions. Pizza for one does not allow using a type parameter in this way. For the sake of the argument we nevertheless present a hypothetical mixin solution in Pizza syntax in gure 1.3. A \mixin class" is like a function which can create a subclass implementing the Searchable interface for any class meeting the required type constraint. The solution with a mixin is not ideal either. Sometimes we want to a ect the appropriate classes directly rather than through subclassing. In this case mixin classes will not work. Another problem with mixin classes is that the mixin's implementation should sometimes be dependent on the base class to provide a more e cient implementation in particular cases. As an example consider a collection which stores its elements in a hash-table. It would be more e cient to implement the SearchableMixin by hashing rather than by enumeration. We could try to accomplish Imperative languages have an if-then-else statement. Functional language provide an if as function. Logic languages can make decisions by \pattern matching". Etc. 1.6. MOTIVATING EXAMPLES 19 interface Enumerable { Enumeration elements(); } interface Enumeration { boolean hasMoreElements(); El next(); } abstract class Searchable< El implements Equality > implements Enumerable { boolean contains(El e) { boolean found = false; Enumeration elems = elements(); while (!found && (elems.hasMoreElements())) found = e.equal(elems.next()); return found; } } Figure 1.2: Abstract Class Implementation of Searchable class SearchableMixin > > extends Super implements Searchable { boolean contains(El e) { ... } } Figure 1.3: Mixin implementation of Searchable 20 CHAPTER